Lambda the Ultimate

Hi,

I have just released Neko 1.0, which is an intermediate programming language with its embedable virtual machine. It might be very interesting for language designers since Neko have been designed so you can generate from your language to Neko and then reuse the virtual machine and libraries provided. You can then concentrate on the design and let Neko take care of the runtime.

More informations at http://nekovm.org.

If you have questions or comments, please feel free to ask.

(note the complementary thread)

Given an imperatively styled program in C, with complex shared state, how would people suggest converting it to functional style?

The program I'm working with is Chromium, which implements a stream-processing model over the OpenGL API, so that the calls from a graphics program (e.g. Quake) get turned into a stream of function calls that can be filtered/modified.

To do this, Chromium contains a "state machine" which tracks all state contained in OpenGL: lighting, raster-position, textures, matrix-stacks, etc. etc.

Via google I found HOGL, a functionalish Haskell binding for OpenGL that lets you do things like:

demo0 = runGraphics ( do
    w <- openWindow "Demo 0" (400, 400)
    print "Demo0 a very simple Hogl program"
    print "press any key to quit"
    draw w (WithColor blue
            (Translate (0,0,-50)
             (Scale (80,80,80)
              (Rotate 36 (1,1,0)
               (cube 1)))))
    getKey w
    closeWindow w
    )

- that is, you can do some state-changes (here setting the current color and changing the modelview matrix) in a functional style.

..anyway, how would people suggest to deal with a large state-machine like that in OpenGL? Are there tools out there for semi-automation of the process?

Is it just me? Or is the LtU forum usability suboptimal? When discussions grow moderately large i find it almost impossible to keep track and I generally give up reading the threads.

I don't watch the forum all they. I generally just drop by a few times a day to see what's new. Discussions tend to diverge into a few different threads, some of which are more interesting than others. Based on this I have two basic needs. I need to be able to easily see which threads have new posts in them, and I would like to browse the threads separately, like I would if it was a usenet group.

Currently I can easily see which threads have new posts, but because of the way this is implemented I have to search for the string "***" to find the new entries. In addition it's very hard to keep track of the various sub-threads. The way the threads are indented is also not very good. I appreciate the idea, but when threads get really deep readability suffers.

IMO the ideal solution would be a threaded forum that has a two-pane solution where the threads are in one pane and the currently active message are in the other. Topics should be ordered according to the latest post, and each discussion should mark clearly if it contains new posts. When you expand a thread, it should be possible to see which thread(s) contain new posts, and expand just that thread. It would also be cool if you could "flatten" a thread at arbitrary level, if you wish to view many articles simultaneously in the view pane.

I don't know about what web forums are available, but the ones that seem to be most popular also seem to be the simplest. They all offer a flat model without threading, which IMO sucks.

Am I alone in thinking that the LtU forum is in dire need of an upgrade? And does anyone know about *good* forums that meet the criteria I have listed?

I noticed the new (to me) language "Qu" chooses to implement type-checking via invariants (see http://centrin.net.id/~marc/example.html).

(invariants, contracts, validators - all refer to the same thing here. any further names?)

Since this is more expressive and potentially "safer" than any typing systems I'm aware of, I'm wondering

• how much prior work has been done on such systems?
• why isn't this more common as a safety mechanism in dynamic languages?

and perhaps more difficult:

• what is the "most complex" STATIC type system currently around, in terms of doing compile-time analysis for such value-constraints?

This appears to have been discussed very briefly here, but maybe I missed something.

Chris Double's recent post mentioning Thinking Forth reminded me of FreeTechBooks.com.

Looks like a good place for everybody to check and add their entries, in case they haven't been submitted yet.

For example, neither of the two books mentioned recently by Ehud is listed in the Common Lisp category yet.

I am in the process of designing a few domain specific languages. Thus I wondering about if people have suggestions about the design of syntaxes. It's generally not a topic of LtU. Nonetheless it is a practical problem for language designers. In a few cases, syntax does make a difference. e.g. Python and Lisp. Maybe it's a vague question. However I don't know how I could bring orderness to this topic.

This paper explores the empirical results of a number of recent (and not-so-recent) papers showing that larger software components are proportionately much more reliable than smaller software components within the same system up to a certain size after which they rapidly deteriorate. This is strongly counter-intuitive to basic notions of software engineering such as modularisation.

The paper first demonstrates that a logarithmic distribution of fault with component complexity closely fits the observed data over a range of component sizes and languages up to around 200 lines or so, (deemed medium size here), after which approximately quadratic behaviour is observed. The paper will review mitigating influences for this non-intuitive behaviour before concluding that none is really satisfactory. It then unites this complex behaviour in a simple mathematical model of the physiology of the human two-level memory system. The resulting component fault rate model accurately predicts the observed data for all languages in this study.

JavaDocs for those who hesitates to download it.

Since this seems to be a popular topic within the OOP thread, I thought I'd break it out on its own and toss in my $2e-2 worth.

Now, it seems that expressivity has something to do with how we use languages to solve problems. In particular, it seems to be a measure of how easy it is to write a solution to a problem in a given language. "Ease" is fairly nebulous to define, so let's try some simple-minded metrics as a starting point. I argue that compressed program length is a reasonable metric. A shorter program has fewer overall symbols to parse and comprehend. If the meaning of those symbols is very intricate and codependent, very terse code might be difficult to understand (like, say, sed/awk). However, nobody can argue that a short string of symbols with lots of meaning is lacking in *expressivity*. So ease of comprehension should not really be a factor in this measure.

Now, how do we use program length to measure expressivity? First, we need a problem set. Since a Turing machine is a solution to some problem, let us simply consider the set of all Turing machines whose length is less than or equal to N. Call this set P. Next, let us suppose that we have a magical function M, a given language L and a specific Turing machine T in P. M(L, T) gives us the compressed length of the smallest program in L that is equivalent to T. To determine the average expressivity of L, we simply take the average of M(L, T) / M(T, T) for all T in P. Let us call this value E(N).

I claim that E(N) is a reasonably objective metric for the expressivity of L. It measures how many symbols are needed to solve a given problem in L. Naturally, M is most likely undecidable, so we can't actually compute it. But I hope it's apparent that if we could at least *estimate* M to a high degree of confidence, that E(N) would be computable, and possibly even useful.

Wouter van Oortmerssen's thesis on Aardappel is a pretty fascinating read, and I like some of the concepts behind visual programming, but is it practical? is there any way VPL's will ever catch on?